CISCO SPCOR, JNCIP, SERVICE PROVIDER

Effect of Route Summarization and LDP updates

ylmva1

While studying for SPCORE I learned about this behavior:

And I tested this in Junos using routing instances and lt interfaces: 

 [edit routing-instances]
 ylara@R1# show | display set relative
 set R1 instance-type virtual-router
 set R1 interface lt-0/0/0.1
 set R1 interface lo0.1
 set R1 protocols ospf area 0.0.0.1 interface lo0.1
 set R1 protocols ospf area 0.0.0.1 interface lt-0/0/0.1
 set R1 protocols ldp explicit-null
 set R1 protocols ldp interface lt-0/0/0.1
 set R1 protocols ldp interface lo0.1
 set R2 instance-type virtual-router
 set R2 interface lt-0/0/0.2
 set R2 interface lt-0/0/0.3
 set R2 interface lo0.2
 set R2 protocols ospf area 0.0.0.1 interface lo0.2
 set R2 protocols ospf area 0.0.0.1 interface lt-0/0/0.2
 set R2 protocols ospf area 0.0.0.1 interface lt-0/0/0.3
 set R2 protocols ldp explicit-null
 set R2 protocols ldp interface lt-0/0/0.2
 set R2 protocols ldp interface lt-0/0/0.3
 set R2 protocols ldp interface lo0.2
 set R3 instance-type virtual-router
 set R3 interface lt-0/0/0.4
 set R3 interface lt-0/0/0.5
 set R3 interface lo0.3
 set R3 protocols ospf area 0.0.0.1 interface lo0.3
 set R3 protocols ospf area 0.0.0.1 interface lt-0/0/0.4
 set R3 protocols ospf area 0.0.0.0 area-range 20.1.0.0/16
 set R3 protocols ospf area 0.0.0.0 interface lt-0/0/0.5
 set R3 protocols ldp egress-policy LDP_ALL
 set R3 protocols ldp explicit-null
 set R3 protocols ldp interface lt-0/0/0.4
 set R3 protocols ldp interface lt-0/0/0.5
 set R3 protocols ldp interface lo0.3
 set R4 instance-type virtual-router
 set R4 interface lt-0/0/0.6
 set R4 interface lt-0/0/0.7
 set R4 interface lo0.4
 set R4 protocols ospf area 0.0.0.0 interface lo0.4
 set R4 protocols ospf area 0.0.0.0 interface lt-0/0/0.6
 set R4 protocols ospf area 0.0.0.0 interface lt-0/0/0.7
 set R4 protocols ldp explicit-null
 set R4 protocols ldp interface lt-0/0/0.6
 set R4 protocols ldp interface lt-0/0/0.7
 set R4 protocols ldp interface lo0.4
 set R5 instance-type virtual-router
 set R5 interface lt-0/0/0.8
 set R5 interface lo0.5
 set R5 protocols ospf area 0.0.0.0 interface lo0.5
 set R5 protocols ospf area 0.0.0.0 interface lt-0/0/0.8
 set R5 protocols ldp egress-policy LDP_LABELS
 set R5 protocols ldp explicit-null
 set R5 protocols ldp interface lt-0/0/0.8
 set R5 protocols ldp interface lo0.5
  
 [edit policy-options policy-statement LDP_R3]
 ylara@R1# show | display set relative
 set term 1 from route-filter 192.168.3.3/32 exact
 set term 1 from route-filter 20.1.0.0/16 upto /24
 set term 1 then accept
 set term 2 then reject 
  
 [edit policy-options policy-statement LDP_R5]
 ylara@R1# show | display set relative
 set term 1 from route-filter 20.1.1.0/24 exact
 set term 1 from route-filter 20.1.2.0/24 exact
 set term 1 from route-filter 192.168.5.5/32 exact
 set term 1 then accept
 set term 2 then reject

Noticed that I added explicit null under protocols LDP, so that the routers advertise label 0 (the EXPLICIT Null label) as my original example. (See the original diagrams). Remember that:

Explicit null (label 0)

  • It is an actual label value: MPLS frames are sent with a label value of 0
  • When the egress signals with label = 0, it is requesting that the packets be sent with a label (label = 0). The egress router itself will remove (pop) the label – UHP (Ultimate Hop Popping)

Implicit null (label 3)

  • It is not an actual label value: MPLS frames are never sent with a label value of 3
  • When the egress signals with label = 3, it is requesting that the packets be sent without a label. The penultimate router (the router right before the egress) will remove (pop) the label – PHP (Penultimate Hop Popping)

Also, I needed to add egress policies under LDP on R3 and R5. These policies were needed because one significant difference between Juniper’s and Cisco’s LDP implementations:

  • IOS allocates and advertises a label for every route in its routing table.
  • Junos allocates and advertises a label ONLY for the primary address of the loopback interface.

The relevant sections of the LDP database, and the routing table on R1, R2, and R3 are shown below:

Without summarization enabled on R3:

R3 advertises 20.1.1/24 and 20.1.2/24 both via LDP and OSPF. As a result:

  • R2 has OSPF routes for 20.1.1/24 and 20.1.2/24 with next-hop R3 AND has labels for both prefixes also from R3.
  • R2 can install LDP routes for 20.1.1/24 and 20.1.2/24 in inet.3, and can allocate and advertise labels for both prefixes to R1.

With summarization enabled on R3:

R3 advertises labels for 20.1.1/24, 20.1.2/24 and 20.1/16 via LDP (because of egress policy), but it ONLY advertises 20.1/16 via OSPF.

  • R2 ONLY has OSPF routes with next-hop R3 AND a label from R3 for 20.1/16
  • R2 can ONLY install an LDP route for 20.1/16 in inet.3, and can be allocate and advertise a label for that prefix to R1.

Related posts